1. Field of the Invention
This invention relates to bus architectures and particularly to low latency shared bus architectures.
2. Description of Related Art
A bus is a communication path between various devices of an electronic system. For example in a computer system, the central processing unit (CPU) communicates with main memory through a memory bus. Peripheral devices may also be connected to the memory bus or connected to the CPU through a separate IO bus.
Buses can be divided into two general categories: point-to-point buses and shared buses. A point-to-point bus connects only two bus devices together. A shared bus can be used by more than two bus devices. Thus the number of buses required for communication depends on whether point-to-point or shared buses are used. For example, four bus devices require six point-to-point buses to communicate with each other, but four bus devices can communicate through a single shared bus. With a shared bus architecture all four bus devices can share a single bus.
Point-to-point buses have the advantage of lower latency, minimal bus contention, and the ability to support multiple simultaneous data transfers. However, the large number of buses used in a point-to-point bus architecture requires a large amount of chip or board area.
Since only a single shared bus can support multiple bus devices, the chip or board area required to implement a shared bus architecture is much less than is required by a point-to-point bus architecture. The primary disadvantage of the shared bus is that arbitration must be performed so that the bus devices can efficiently share the shared bus. Furthermore, device identification is necessary on the bus so that a bus device only receives or responds to signals directed towards that bus device.
With the increasing complexity of electronic systems, data buses have increased in width. The wide data buses preclude the use of many point-to-point buses when chip or board area is costly. Therefore, shared buses are commonly used in complex electronic systems.
FIG. 1 shows a block diagram of a conventional shared bus system 100. Bus device 120, bus device 130, bus device 140, as well as other possible bus devices (not shown) are coupled together by a shared bus 190, which contains an address bus 150, a data bus 160, and a control bus 170. On some shared bus systems, the address values and data values are multiplexed on a single combined address/data bus. Each bus device has a bus request output terminal R, a bus grant input terminal G, address terminals ADDR, data terminals DATA, and control terminals CTRL. The bus request output terminals and bus grant input terminals are coupled to a bus arbiter 110. If bus device 120 wishes to use shared bus 190, bus device 120 must drive a request active state on bus request output terminal R. The signals, specifically the request, grant, and select signals, in the embodiments and timing diagrams described herein use logic high as the active state and logic low as the inactive state; however, logic low is also commonly used as the active state with logic high being the inactive state. Bus arbiter 110 monitors the bus request signal on a corresponding bus request input terminal. Since arbiter 110 has a bus request input terminal for each bus device, the bus request input terminals are labeled R_x, where x is a number corresponding to each bus device. If shared bus 190 is not in use, bus arbiter 110 drives a grant active state on the grant output terminal coupled to grant input terminal G of bus device 120 to a grant active state. If two devices request the bus simultaneously bus arbiter 110 can use a priority scheme to determine which device receives the bus grant.
The use of separate bus request and grant lines for each device is commonly referred to as independent requesting arbitration. Other commonly used arbitration schemes include daisy chaining and polling.
A bus device which is granted the use of the bus is commonly referred to as a bus master. The bus master communicates with another bus device, which is commonly referred to as the bus slave. A bus device may be capable of being a master only, a slave only, or both a master and a slave. If bus device 120 is granted the bus, bus device 120 becomes the bus master. Bus device 120 then drives address bus 150 and control bus 170 through address terminals ADDR and control terminals CTRL, respectively, to initiate a data transfer. Specifically, bus device 120 would drive address signals onto address bus 150 through address terminals ADDR and control signals onto control bus 170 through control terminals CTRL. Control bus 170 can contain control signals which indicate, for example, the size of the data transfer and the direction of data transfer (i.e. a read or a write).
Typically each bus device is given a range of addresses for the various data under control by that bus device. Therefore, when the bus master drives a device address corresponding to the desired bus slave onto address bus 150, each bus device must monitor and decode the device address on address bus 150 to determine whether the device address driven by the bus master matches the device address of the bus device. The bus device with a device address which matches the device address driven by the bus master becomes the bus slave. For example, if bus device 120, currently the bus master, wishes to read data from bus device 140, bus device 120 must drive the device address for bus device 140 onto address bus 150. Every other bus device then decode the address to determine whether the device address driven by bus device 120 matches the address of the bus device. In this example, only bus device 140 finds a matching device address. The time for bus device 140 to decode the address adds to the latency of shared bus 190.
FIG. 2 illustrates the timing of bus arbitration for a typical synchronous shared bus writing data from a bus master to a bus slave. At a first rising edge 201 of clock signal CLK, the requesting bus device drives a request active state on bus request output terminal R, which provides request signal REQUEST to bus arbiter 110. At a later rising edge 202, bus arbiter 110 grants the use of shared bus 190 by driving a grant active state onto the grant output terminal coupled to bus grant input terminal G of the requesting bus device, to provide grant signal GRANT. When the requesting bus device receives a grant active state, the requesting bus device becomes the bus master. At rising edge 203, the bus master drives bus address value 231 on address bus 150, which corresponds to the desired bus slave, to which the bus master wishes to write data. The non master bus devices decode address value 231 to determine which bus device is the desired bus slave. At rising edge 204 of clock signal CLK, the bus master writes address value 232 on address bus 150 and data value 241 on data bus 160. Thus, the selection of the bus slave causes a latency of one clock cycle before data is transferred in a synchronous shared bus system.
A read transfer has similar timing to the write transfer shown in FIG. 2. However, the data would be driven by the bus slave beginning at rising edge 204 of clock signal CLK. If shared bus 190 is used for posted read requests (as explained below), the timing would be identical to FIG. 2 except that no data is written at rising edge 204 of clock signal CLK. Instead at a later time the bus slave will request the use of the bus to respond to the posted read request. Thus, for a posted read request, the latency of bus slave selection accounts for one-third of the total time required for the posted read request.
Depending on the actual implementation of the shared bus 190, other control signals may be beneficial. For example, if each bus device uses data FIFOs as a buffer, status flags such as FIFO full and FIFO empty can be used to indicate whether the bus slave is ready to receive or transmit data. In another bus system a device ready signal may be used on control bus 170.
Another problem with using a shared bus scheme is that only one bus master can use the shared bus at a time. Therefore, if a bus master is waiting for data from a bus slave, other bus devices cannot use the bus. One way to ease the bus contention problem is to use posted read requests. In a posted read request, the bus master sends a read request to a slave and then relinquishes the shared bus. When the bus slave is ready to respond to the read request, the bus slave initiates a request for the bus to send the data to the original bus master.
When the bus slave responds to the read request, the original bus master must determine which posted read request is being answered. A tagging scheme can be used to mark each of the outstanding posted read requests. The circuitry for tagging and identification of responses can be complicated and can add to the latency of the shared bus architecture.
Hence, methods and circuits which reduce the latency of a shared bus architecture are desired. Specifically, the methods or circuits should remove the latency caused by determining the desired bus slave and the complexity due to tagging posted read requests so that a bus device can determine which posted read request is being answered. Furthermore, the circuits should not require excessive board or chip area.